The following notions are used in this application:
“Data management system” is an entity, which comprises one or more databases and/or data management systems, whereby the system is responsible for reading the data structures contained in the databases and/or data management systems and for changing these data structures.
“Database” is an information structure, which comprises one or more data elements, and the use of which is controlled by the data management system. The invention is applicable both in relational databases and in databases of other forms, such as in object-oriented databases.
“Data element” is an information structure, which can comprise other data elements or such data elements, which can be construed as atomary data elements. For instance, in a relational database data elements are represented by tables comprising rows. The rows comprise fields, which are typically atomary data elements.
“Database operation” is an event, during which data elements are read from the database, during which data elements of the database are modified, during which data elements are removed from the database, and/or during which data elements are added to the database.
“Transaction” is a plurality of database operations acting on the data elements. A transaction can also comprise further transactions.
“Database Schema” is the structure of a database system, described in a formal language supported by the database management system (DBMS). In a relational database, the schema defines the tables, the fields in each table, and the relationships between fields and tables.
“Database Catalogue” logically partitions a database so that data is organized in ways that meet business or application requirements. Each logical database is a catalogue and contains a complete, independent group of database objects, such as tables, indexes, procedures and triggers. Each of these catalogues can act as a master or replica database. This makes it possible, for example, to create two or more replica databases into one physical database. It is also possible to have one or more catalogues in this same local database that represent master database(s).
“Database Node” is a database catalogue, which has been defined to act as a master or replica and thus participates in a hierarchy of synchronized databases.
“Master database” is a database catalogue in a database synchronization system that contains the official version of synchronized/distributed data. A master database can have multiple replica databases.
“Replica database” is a database catalogue in a database synchronization system that contains a full or partial tentative copy of the master data.
“Publication” is a set of data in a database catalogue that has been published in master database for synchronization to one or multiple replica databases.
“Synchronization” is operation between replica and master database catalogues in which changed data is exchanged between the catalogues. In one known embodiment, this means propagation of Intelligent transactions from replica to master and subscribing to a publication to download changed data from master to replica, [1] EP 0 860 788.
“Schema revision” is a snapshot version of a schema that is identifiable by logical name or version number.
“Schema script” is a script that creates a schema or creates a new revision of an existing schema of a database node.
“Schema subscript” is a schema script that is executed from another schema script.
“Schema script publication” is a system publication that contains the schema scripts of the database hierarchy.
A schema is a representation of the structure of the database that illustrates what kind of data is stored in the database. In distributed database management environments, it must be possible to distribute new schemas as well as modify the existing schemas of the databases of the system in a flexible and controllable manner.
FIG. 1 illustrates an example of prior art database arrangement 100. The database system includes a server 101 with an application master database 102. This application master database includes a schema master of the data stored in the database. The database system also includes two servers 111 and 121 with application replica databases 112, 122. The application replica databases can maintain a full or partial copy (replica) of the application master database servers' data using suitable data synchronization technology, such as functionality disclosed in patent application document [1] EP 0 860 788. The application replica databases include schemas 113, 123, which may be a full or partial copy of the schema 103 of the application master database. Some prior art solutions for managing schemas in distributed database systems are described in documents [2] U.S. Pat. No. 5,806,066, [3] WO 00/45286 and [4] WO 00/04445.
In the prior art implementations schema upgrades are made in the master and these upgrades are distributed to the replicas transparently using some hard-coded rules. This approach introduces some problems that make operating large multi-database systems difficult:                There is no possibility in prior art implementations to control the schema upgrade process programmatically. For instance, sometimes the nature of a schema modification operation require that services for all on-line users of the database are disconnected while the schema is being upgraded. This requires programmatic control over the upgrade process in replica databases.        There is no overall view about the upgrade status of different databases of the system. Failed upgrades are not reported anywhere and the system operator does not necessarily know, which replicas have upgraded to new revision and which have not yet done so.        If the automatic upgrade fails, there is no possibility for error handling and system recovery. There is neither a possibility to prevent such errors. Typically the replica database must be recreated from scratch in this kind of situation.        Upgrading a system where different replicas can have different schemas and where replicas can have local tables that are not defined in the master is a difficult task.        The prior art technology does not support outsourcing the runtime configuration control of distributed systems to third parties.        
For these reasons, the database schemas of prior art distributed systems are typically not well manageable.